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TREE-BASED CERTIFICATE REVOCATION SYSTEM 

This application is based on U.S. provisional patent application No. 
60/006,143 filed on November 2, 1995. 

TECHNICAL FIELD 

5 The present invention relates generally to secure communications and more 

particularly to schemes for certificate management. 

BACKGROUND OF THE INVENTION 

In many settings, it is useful to certify data, as well as to revoke data that 
was previously certified. For instance, in a Public Key Infrastructure (PKI), it 
10 may be useful to certify users' public keys. Such certification may be provided in 
the form of a certificate which contains the certified data and vouches authenticity 
of the certified data. 

In a digital signature scheme, each user U chooses a signing key SK U and a 
matching verification key, PK„. User U uses SK, to compute a digital signature of 

15 a message m, SIGJm), while anyone knowing that PK U is U's public key can 

verify that SIGJm) is U's signature of m. Finding SIGJm) without knowing SK U 
is practically impossible. On the other hand, knowledge of PK U does not give any 
practical advantage in computing SK a . For this reason, it is in U's interest to keep 
SK U secret (so that only he can digitally sign for U) and to make PK U as public as 

20 possible (so that everyone dealing with U can verify U's digital signatures). At 
the same time, in a world with millions of users, it is essential in the smooth flow 
of business and communications to be certain that PK U really is the legitimate key 
of user U. To this end, users 1 public keys are often "certified" by a certificate 
that serves as proof that U is the legitimate owner of PK tt . At the same time it is 

25 also useful to be able to revoke some of the already-issued certificates when U is 

no longer the legitimate owner of PK U (for whatever reason) and/or when SK U has 
been compromised. Of course, the need for certification and certificate revocation 
extends beyond certifying public keys. 



PCT/US96/17374 

In many instances, certificates for users' public keys are produced and 
revoked by certifying authorities called CA's. A complete public key 
infrastructure may involved other authorities (e.g., PCAs) who may also provide 
similar services (e.g., they may certify the public keys of their CA's). The 
5 present discussion can be easily applied to such other authorities in a straight- 

forward manner. 

A CA may be a trusted agent having an already certified (or universally 
known) public key. To certify that PK U is U's public key, a CA typically digitally 
signs PK U together with (e.g., concatenating it with) U's name, a certificate serial 
10 number, the current date (i.e., the certification or issue date), and an expiration 

date. The CA's signature of PK U is then inserted in a Directory and/or given to U 
himself. Note that, before certifying U's public key, it is necessary to perform 
additional steps, such as properly identifying user U. However, these additional 
steps are optional. 

15 Upon receiving the (alleged) digital signature of user U of a message M, 

S1GJM), a recipient R needs to obtain a certificate for PK U . (In fact, SIGJM) 
may be a correct digital signature of M with respect to some public key PK U7 but 
R has no guarantee that PK U is indeed U's public key. Recipient R may obtain 
this certificate from the Directory, or from his own memory (if he has previously 

20 cached it), or from U himself. Having done this, R verifies (1) the correctness of 
the CA's certificate for PK U with respect to the CA's public key, and (2) the 
correctness of S1GJM) with respect to PK U . If the CA's public key is not 
universally known, or cached with R, then a certificate for the CA's key may also 
be obtained. 

25 Certificate retrieval is thus possible, although not necessarily cheap. 

Unfortunately, however, this is not the only retrieval that R needs to do. In 
addition, it is important that R makes sure that the certificate for PK U has not been 
revoked. This check, of course, may not be needed after the certificate's 
expiration date, but may be needed during the certificate's alleged lifetime. A 

30 user's certificate can be revoked for a variety of reasons, including key 

compromise and the fact that the user is no longer associated with a particular CA. 
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To enable a recipient to establish whether a given certificate has been 
revoked, it is known to have each CA periodically issues a Certificate Revocation 
List (CRL for short). A CRL may consist of the issuer's digital signature of a 
header comprising the issuer's name (as well as the type of his signature 

5 algorithm), the current date, the date of the last update, and the date of the next 
update, together with a complete list of revoked certificates (whose date has not 
yet expired), each with its serial number and revocation date. Since it is expected 
that a CA revokes many certificates, a CRL is expected to be quite long. It is 
envisaged that the CRL is provided to a directory who may then distribute the 

10 CRL to end users. 



After performing some checks on the CA's CRL (e.g., checking the CA's 
digital signature, checking that the CRL has arrived at the expected time, that a 
certificate declared revoked in the previous CRL of that CA - and not yet expired 
- still is revoked in the current CRL, etc.), the Directory stores it under its CA 
15 name. 

When a user queries the Directory about the revocation of a certificate 
issued by a given CA, the Directory responds by sending to the user the latest 
CRL of that CA. The user can then check the CRL signature, the CRL dates (so 
as to receive a reasonable assurance that he is dealing with the latest one), and 
20 whether or not the certificate of interest to him belongs to it. 

While CRLs are quite effective in helping users establishing which 
certificates are no longer deemed valid, they are also extremely expensive, because 
they tend to be very long and need to be transmitted very often. 

The National Institute of Standard and Technology has tasked the MITRE 
25 Corporation to study the organization and cost of a Public Key Infrastructure (PKI) 

for the Federal Government. This study estimates that CRLs constitute by far the 
largest entry in the Federal PKI's cost list. According to MITRE's 
estimates/assumptions, in the Federal PKI there are about three million users, each 
CA serves 30,000 users, 10% of the certificates are revoked (5% because of key 
30 compromise and 5% because of change in affiliation with the organization 

-3- 



WO 97/16905 



PCT/US96/17374 



4; 

connected to a given CA), CRLs are sent out bi-weekly, and the recipient of a 
digital signature requests certificate information 20% of the time (assuming that 
the remaining 80% of the time he will be dealing with public keys in his cache). 
The study envisages that each revoked certificate is specified in a CRL by means 
5 of about 9 bytes: 20 bits of serial number and 48 bits of revocation date. Thus, 
in the Federal PKI, each CRL is expected to comprise thousands of certificate 
serial numbers and their revocation dates; the header, however, has a fixed length, 
consisting of just 51 bytes. 

At two cents per kilobyte, the impact of CRL transmission on the estimated 
10 yearly costs of running the Federal PKI is stunning: if each federal employee 
verifies one hundred digital signatures per day on average, then the total PKI 
yearly costs are $10,848 million of which 10,237 million is due to CRL 
transmission. If each employee is assumed to verify just five digital signatures a 
day on average, then the total PKI yearly costs are $732 million, of which 563 
15 million is due to CRL transmission. 

The MITRE study thus suggests that any effort should be made to find 
designs alternative to and cheaper than conventional CRL's. 

In addition, we contend that it is possible for a user to query the Directory 
with a serial number not corresponding to any issued certificate. (Indeed, while 

20 many times the user has already seen a certificate and accesses the Directory just 
to confirm the current validity of that certificate, at other times the user wishes to 
obtain the corresponding certificate from the Directory). If the corresponding 
certificate does not exist, the Directory is at a loss as to how to proceed. If the 
Directory responds truthfully, it may not be believed by the user. If the Directory 

25 gives the users all the certificates in its possession (or those relative to a given 
CA) the user may suspect that the Directory left out the certificate of interest. 
Indeed, even if the Directory gives the user the latest CRL of a given CA, this 
does not prove to the user that the certificate in question does not exist. (In fact, 
the actions of the Directory may actually be interpreted as saying that the 

30 certificate is valid because it does not appear to have been revoked.) Thus in this 

thorny situation the Directory would have to be trusted. 
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BRIEF SUMMARY OF THE INVENTION 

To avoid the dramatic CRL costs, a novel Certification Revocation System 
is described, where requesting users no longer receive the latest list of revoked 
certificates (of a given CA). The scheme utilizes a known tree-based 
5 authentication technique in a novel way to overcome the problems associated with 
the prior art. 

It is thus a primary object of this invention to provide certificate 
management without providing CRL's to a user requesting information about the 
certificate (e.g., its validity). Although special CRL's still may be used between 
10 C A' s and the Directory in this scheme, the tree-based technique allows the 

Directory to convince users of whether or not a given certificate is still valid in a 
way that is essentially individualized, and thus quite compact and convenient. 

BRIEF DESCRIPTION OF DRAWINGS 

The sole figure shows a Merkle tree that is used in connection with the 
15 present invention. 

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 

An interesting authentication scheme is described in U.S. Patent No. 
4,309,569 to Merkle where it is used in connection with digital signatures. The 
sole figure shows a simple Merkle tree, T. Merkle is hereby incorporated by 

20 reference and familiarity with the Merkle scheme is assumed in the following 

discussion. The Merkle scheme has been shown to be useful for applications other 
than digital signature schemes; in particular for constructing special and more 
efficient mathematical proof systems. The object of the present invention is to 
show how Merkle' s scheme can yield certificate revocation systems more efficient 

25 than known CRL-based systems. 

Briefly, a Merkle tree consists of a tree (binary, ternary, binary and 
ternary, etc.) with values corresponding to the tree nodes in the following manner. 
For simplicity, consider a full binary tree T with n = 2" leaves and let H be a 
one-way hash function mapping strings of arbitrary length into B-bit strings (that 
30 is, a function H for which it is difficult to find two different strings x and y such 
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that H(x) = H(y)). Then, T is a Merkle tree if the value corresponding to each 
internal node equals the one-way hash of the values corresponding to the children 
thereof. Developing a minimum of terminology, let N be an internal node where 
the left child is L and the right child is R, and let V L be the value corresponding 
to L and V R the value corresponding to R (we shall refer to V L and V R as, 
respectively, a left-value and a right-value). Then, for T to be a Merkle tree, the 
value corresponding to node N must be the B-bit value HO/lVr), where V L V R is 
the concatenation of V L and V R (although V L and V R may be combined by 
operations other than concatenation). 

It is a well known property of a Merkle tree that (unless one "breaks" the 
one-way hash function - i.e., unless one is capable of finding two different strings 
x and y such that H(x) = H(y) - which would require an extraordinary amount of 
computation to do) changing the value of any node in a Merkle tree causes the 
root value to change also. It is also known that to verify whether the value of a 
given node N is authentic with respect to the root value of a Merkle tree, it 
suffices to use very few values of the tree. Indeed, it suffices to use the 
authentication path of node N, which is the sequence of values corresponding to 
the siblings of the nodes along the path from node N to the root. Each of the 
values of the nodes in the authentication path is an authentication value. If most 
of the internal nodes of a Merkle tree have two children, it is immediately seen 
that an authentication path comprises roughly k authentication values where k is 
the depth of the tree, even though the total number of nodes can be as much as 2 k . 
(To facilitate the verification of the value corresponding to a node N whose 
position within the tree is unknown, the sequence of authentication values for N 
can be given by specifying whether each value is a left value or a right value. 
Vice versa, it is well known that if the authentication path of node N is verified as 
valid, the fact that each authentication value is a left or right value determines the 
position of node N within the tree.) 

Let us now recall, by way of example, how one can verify that the value of 
a node N is correct with respect to the value of the root. Referring to the sole 
figure, let N be the second leaf from the left in the tree T. Then, V^, is the value 
of N; V is the value of the root; and the authentication path of N consists of the 
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following sequence of three values: the left value Vqoo, the right value V 01 , and the 
right value V,. Then, because is a left value, one computes HCVoo^Voq,) and 
calls Vqo the result. Then, because V 01 is a right value, one computes H(Voo,V 01 ) 
and calls the result V 0 . Finally, because V, is a right value, one computes 
5 H(V 0 ,\\) and verifies that the result equals V, the root value. 

Notice that a Merkle tree needs not to be a full binary tree. (For instance, 
if it is not, one can add dummy nodes to make it a full binary tree. Alternatively, 
instead of creating artificial nodes, it is possible to deem the value corresponding 
to any missing node a special, predetermined value, denoted by EMPTY in the 
10 sole figure.) Of course, if the tree is not sufficiently full, then authentication paths 
may become needlessly long. 

One way to store certificate information in a Merkle tree includes 
associating pieces of the certificate information to leaves of the Merkle tree. For 
instance, the pieces of information are the values corresponding to the leaf nodes, 
15 while the one-way hash function determines the values of internal nodes of the 

tree, including the root. (As discussed elsewhere herein, however, it is possible to 
make certificate information correspond to internal nodes, including the root.) 

Each node of the Merkle tree that corresponds to a portion of the certificate 
information is deemed a "certificate node". A simple way to associate certificate 
20 information to certificate nodes includes having as many certificate nodes as there 
are certificates, and making information about an individual certificate be the value 
corresponding to an individual certificate node. 

Instead of having the CA provide information directly to users, in a 
preferred embodiment, one or more intermediaries interact with most of the users. 

25 The one or more intermediaries obtain the certificate information from the CA. 

(Whithin an authenticated tree, we refer to a value belonging to the authentication 
path as authenticating value,) The CA may provide an intermediary with an entire 
authenticated tree indicating which certificates have been revoked. As illustrated 
below, an authenticated tree is a Merkle tree (storing certificate information) 

30 having a root value that is authenticated (e.g., digitally signed) by the CA. To 



• 
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prove to an end user that a given certificate is revoked, the intermediary provides 
the user with (a) the value of certificate node N of the authenticated tree, where N 
is the certificate node whose value indicates that the certificate in question has 
been revoked; (b) the authentication path of node N in the tree; and (c) the digital 
5 signature of the CA of the root value of tjie tree. (Recall that this signature may 
include date information and additional information). 

The end user, upon receiving (a), (b), and (c) from the intermediary, 
verifies that the digital signature of the CA is valid, thus learning the true root 
value of the tree. Then, the user also verifies that the authentication path for node 

10 N is valid with respect to the root value, thus learning the true information about 

the certificate in question. (Here by "true" we mean deemed true by the CA.) 
The user also verifies that the date information, if any, of the CA's signature of 
the root value is the expected date. (For instance, if the CA includes in the date 
information not only the date in which the authenticated tree was constructed, but 

15 also the date by which the CA intends to update the authenticated tree, the user 

also verifies that he is dealing with the latest authenticated tree.) 

Notice that if the user trusts the CA, the user needs not trust the 
intermediary. Indeed, if the intermediary wishes to provide the user with false 
information about the certificate in question, the intermediary needs to perform an 
20 extraordinary amount of computation. For instance, if the intermediary wishes to 

modify the value corresponding to node N, the intermediary would have to either 
change the root value and therefore be able to forge the digital signature of the 
CA, or be able to break the one-way hash function. 

Notice that the amount of data that an honest intermediary provides to a 
25 user in order to allow the user to verify that the revocation information about a 

given certificate is authentic is not very large, especially when compared to a 
conventional CRL. Indeed, the bulk of the data provided to the user consists of 
the authentication path of the node N. For instance, if there are 3,000 revoked 
certificates in the tree, then certificate information about these 3,000 certificates 
30 could be associated to the leaves of a Merkle tree of depth 12. Thus, there are at 

most 12 values in the authentication path of node N. If each value is 200 bits long 
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(which is more than currently advocated for one-way hash functions), the total 
length of the authentication path is about 2400 bits, (more precisely, it is 1 1 times 
200 bits for the values of internal nodes plus the length of the value of a leaf node. 
In fact, the authentication path of a certification leaf consists of one leaf value and 

5 eleven internal node values. As we shall see herein, however, even the length of 
leaf values can be made to be relatively small for authentication purposes.) This is 
much shorter than a CRL comprising the serial numbers and revocation dates of 
3,000 revoked certificates. Of course, the new system also includes a digital 
signature of the root and date information, but so does the CRL system. 

10 Therefore, we succeed in a much more efficient way than a CRL system in having 

authentic information about certificates be provided to the end user by an 
intermediary without having to trust the intermediary. 

In the example given above, an authenticated tree is used by the CA to 
provide the intermediary with data enabling the intermediary to prove to end users 

15 that a given certificate of the CA has been revoked. The CA may also use 

authenticated trees so as to enable the intermediary to prove much more general 
certificate information. For instance, as we have said, it should be possible for an 
intermediary to prove to end users not only the certification status of issued 
certificates, but also that (alleged) certificates have never been issued by the CA. 

20 For instance, this could be done as follows: Assume that, like in the PKI 

envisaged in the MITRE study, a serial number consists of a twenty-bit string. 
Then, each possible serial number can be put in correspondence with a leaf of a 
full binary tree of the depth twenty. Then, for each serial number, X, the C A 
creates and X-value such as "certificate number X has not yet been issued" , or 

25 "certificate number X (has been issued and) is currently valid", or "certificate 

number X has been revoked (on date dx and for reason rx)", whichever is the 
case. Each X value is then associated to a leaf of its own. Once more, in this 
example, certificate nodes are leaf nodes. Then the CA associates values to all 
other nodes of the binary tree of level twenty using a one-way hash function H so 

30 as to form a Merkle tree. Then, the CA digitally signs the root value, thus 

obtaining an authenticated tree. An intermediary can use such a tree to efficiently 
prove to any end user the certification status of any possible serial number for a 
certificate, and thus the status of any possible certificate. 
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Note that it is possible to use the position of a node in an authenticated tree 
to convey information. For instance, in the above example, the CA may place 
information about certificate number X in leaf X so as to avoid having to store the 
serial number in the leaf. (Indeed, a leaf of a binary tree of depth twenty can be 
5 associated to a unique twenty-bit string in a natural way. Consider the path from 
the root to the leaf. If the first node from the root is a left child, we write "0". If 
the next node is a right child, we write " T . Thus, upon reaching the leaf in 
question, we have written a twenty-bit string X that uniquely identifies the leaf.) 
Position information in the tree can be exploited using different ways of encoding 
10 positional information. For instance, if the serial numbers of certificates in the 
tree begin with number one, then certificate information for certificate serial 
number one can be placed in the first leaf (i.e., left most terminal leaf), certificate 
information about certificate serial number two can be placed in the second leaf, 
etc. 

15 In addition, it is possible to put information about more than one certificate 

into a single node of the tree so that, for example, if information about two 
certificates were placed in each of the terminal leaf nodes, then information about 
certificate serial numbers one and two could be in the first terminal leaf node, 
information about certificate serial numbers three and four could be placed in the 

20 second terminal leaf node, etc. 

An authority that issues and revokes certificates maps certificate 
information into values. This mapping may be as simple (e.g., the identity 
mapping) or complex as required by the nature of the certificate information. For 
example, if the certificate information consists simply of identifying whether a 
25 certificate is issued, revoked, or expired, then the mapping could be 00=issued, 

01=revoked, (10=expired,) and ll=never issued. In this way, each possible 
value corresponds to different possible states for each certificate. 

As can be seen in the above example, it is possible to store, in a certificate 
node, certificate information about more than one certificate. If the values for M 
30 certificates can be stored in each node, and there are 2 20 possible certificates, then 

the Merkle tree may have 2 20 /M leaf nodes. A proper encoding is used so that the 
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value a certificate node can be understood without ambiguity. For instance, if we 
care about proving information of the type 00=issued, 01=revoked, 10=expired, 
and 1 1 = never issued, and we want every value in the authenticated tree to be 200 
bits long, then information for one hundred certificates may be stored in each 
5 certificate node. One knows a priori that two bits of certificate status about 

certificate number one through one hundred are to be found in the value of the 
first leaf. Further, one knows that the first two bits of that value correspond to 
certificate number one, that the second pair of bits in that value correspond to 
certificate number two, etc. 

As discussed above, it is not necessary for the users to trust the 
intermediary since the intermediary provides certificate information to the users in 
a way that indicates that the CA has authenticated the certificate information. 
Note that an intermediary includes, but is not limited to, a directory, a distributor, 
a redistributor, a user, a CA, a database, a readable computer file, a read-only 
computer file, an entity that has obtained information from another intermediary, 
or any combination of the above. Generally, an intermediary is an entity that 
provides certificate information authenticated by a CA. 

A major advantage of conveying certificate information via authenticated 
trees consists of efficient updating. For instance, in a typical day, a CA may issue 
20 ten more certificates and revoke one previously issued certificate. In such a case, 
the CA may provide the intermediary with a new authenticated tree that contains 
the current certificate information about all certificates. More efficiently, 
however, the CA may provide the intermediary just with the new values of the 
certificate nodes, whose values have changed, together with the digital signature of 
25 the new root (and proper date information). In sum, therefore, the CA sends very 

little information to the intermediary. (Of course, if so wanted, teh CA can send 
additional information. For instance, he may send not just the certified nodes that 
have changed, but values of nodes that have changed and the position of these 
nodes. So doing, he may simplify the work of teh intermediary.) 



10 



15 



30 



The intermediary could use the new received values and the old values and 
the one-way hash function to compute the new Merkle tree, and thus, in 
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10 



particular, the new root value so that the intermediary can check the digital - 
signature of the CA and verify the new authenticated tree. The intermediary is 
now ready to provide a user with updated certificate information. 

The same efficiency can be obtained when the intermediary wishes to 
provide end users proofs of certificate information. For instance, a given user U 
may already be in possession of yesterday's entire authenticated tree. In this case, 
the intermediary can bring the user up to date by providing the user with just the 
values that have changed and the signature of the CA of the new root value. Of 
course, the user may not have yesterday's full authenticated tree, but he may have 
the full authenticated tree of, say, two weeks earlier. In this case, the 
intermediary may still provide the user with just the values that have changed with 
respect to two weeks ago along with the CA's signature of the new root value. 
This may still result in substantial savings. 

The intermediary may know, by keeping track of what was sent to the user, 
15 which authenticated tree the user already knows. Alternatively, the user may 
signal to the intermediary which authenticated tree he already has and the 
intermediary may act accordingly. In general, the intermediary may omit sending 
to the user values that the user already knows. In addition, it is possible for the 
intermediary to obtain some of the authenticated tree information from an entity 
20 other than the CA, in which case the CA may only provide the intermediary with 

authenticated tree information that is not already known by the intermediary. Note 
that it is also possible for the intermediaries to obtain information about the tree 
from other sources, such as other intermediaries. 



In another embodiment of the invention, the CA may make use of two or 
25 more Merkle trees to convey certificate information. For instance, a first tree may 

contain information about issued but non-revoked certificates, and a second tree 
may contain information about revoked certificates. The root values of these trees 
(together with other information deemed proper) may be digitally signed by the 
CA either separately or together, thus making these Merkle tree authenticated 
30 trees. 
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Alternatively, it is possible to have a first authenticated tree containing 
information about all issued certificates and a second authenticated tree containing 
information about all revoked certificates. This embodiment is similar to the two 
tree system described above where one authenticated tree contains information 

5 about issued but non-revoked certificates and the second authenticated tree contains 
information about revoked certificates. However, in the case, knowing the issued 
certificates and revoked certificates makes it possible to determine or ascertain if a 
certificate is valid (i.e., by determining if the certificate is both issued and not 
revoked). It is also possible to construct an authenticated tree containing 

10 information about certificates that have not been issued. In that case, the authority 
can provide an intermediary with information for proving that one or more 
certificate serial numbers (or other appropriate certificate identifiers) do not 
correspond to any certificate that was issued as of a given date. Other possible 
combinations of authenticated trees containing certificate information are possible, 

15 as will become apparent from the following discussion. 

Note that an authenticated tree may be constructed by the CA or by another 
entity, such as the intermediary, and that the other entity may simply present the 
root of the underlying Merkle tree to the CA for authentication. Also, it is 
possible for the CA to authenticate nodes, other than or in addition to the root, of 

20 a Merkle tree. In the case of a node other than the root of a Merkle tree being 
authenticated by the C A, an authentication path can be verified with respect to 
such an authenticated node rather that with respect to the root. It should be noted, 
however, that by authenticating (e.g., digitally signing) one or more nodes of a 
Merkle tree, the CA is actually generating authenticated (sub)trees that are stand- 

25 alone authenticated trees in their own right. 

Note that the certificate information CI corresponding to a certificate node 
N may be one-way hashed prior to being associated to the node. That is, the 
value associated to node N is H(CI) rather than CI. The process of passing from 
CI to H(CI) is a possible mapping step performed by a CA. One advantage of 
30 such a mapping is that if node N is, say, a leaf node, then whenever the value of 
N is used within an authentication path of another node, it only contributes some, 
say, 200 bits to such a path no matter how long CI may be. (Indeed, CI may be a 
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very long string indicating, among other things, the reasons that a certificate has 
been revoked.) On the other hand, when we wish to provide CI in an 
authenticated manner, we reveal CI in full. (See, for example, Leighton et aL). 
Such a full value of CI is first mapped to H(CI) and then this mapped value is 
proved to be the value of a genuine certificate node in an authenticated tree. 

Note also that the intermediary may not directly send data to an end user, 
but cause the end user to receive data (e.g., by someone else, possibly at a signal 
of an intermediary, or by enabling the user to read some data file, or in any other 
manner). 



10 Note that the scheme disclosed herein can be expanded beyond the simple 

type of tree disclosed in Merkle. An example of such expansions are given in 
U.S. patent no. 5,432,852 to Leighton et al, which is incorporated by reference 
herein. In particular, although an authenticated tree may have an underlying 
structure of a tree such as that disclosed in Merkle, the authenticated tree may in 

15 fact may have other interconnections and paths therethrough. Similarly, it is 

possible to have the value of a node depend on the position, P, of the node within 
the tree. For example, in such a case, the value of the node may be H(VL, VR, 
P), where VL is the value of the node's left child and VR is the value of the 
node's right child. Including position information helps prevent attack by someone 

20 who attempts to find two values that hash to an actual node value of an 

authenticated tree. When the node information includes position information, then 
a prospective attacker would have to find values that hashed to the combination of 
the children information and the position information, which is much less likely. 
U.S. patent no. 5,432,852 to Leighton et al. discloses a similar idea used in 

25 connection with a signature scheme. Note also that the hashed value of a node 

could be a hash of the children concatenated with a position of the node within the 
tree or could be a hash of the concatenation of the children and the position. 

In addition, one or more of the nodes containing the certificate information 
(i.e., the certificate nodes), are not all necessarily leaf nodes of the tree, but, 
30 instead, have children of their own. For instance, let N be an internal node whose 
left child has a value VL and whose right child has a value VR, and let CI be 
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some certificate information that we wish to associate to node N. Then, the value 
associated with node N can be made equal to VN=H(VL.VR,CI). 

It should be realized the system disclosed herein facilitates batch 
processing. For example, rather than signing n pieces of certificate information 

5 separately, a CA may "Merkle" hash the quantities so as to obtain a single root- 
value, and then digitally signs the root-value (together with additional quantities if 
desired). This is a way to substitute n individual signatures (that can be expensive 
to obtain) with just one signature and n-J hashing (which are not expensive at all). 
Notice that any signature scheme can be used for the root, including pen-written 

10 signatures, rather than digital ones. 

Notice that a one-way hash function needs not to map every string to values 
having always B bits. For instance, it may map soem strings to 160-bit values and 
some other strings to 200-bit values. Also notice that an authenticated tree needs 
not to be constructed by means of a single one-way hash function. For instance, a 
15 first one-way hash function could be used for nodes at the first level, a second 

one-way hash function for nodes at the second level, etc. More generally, one 
could use a different one-way hash function for each position within the tree. 
Notice, however, that such a collection of one-way hash functions is a single one- 
way hash function for purposes of constructing an authenticated tree. 

20 The foregoing has outlined some of the more pertinent objects and details 

of a preferred embodiment of the present invention. These objects and details 
should be construed to be merely illustrative of some of the more prominent 
features and applications of the invention. Many other beneficial results can be 
attained by applying the disclosed invention in a different manner or modifying the 

25 invention as will be described. Those skilled in the art will recognize that the 

invention can be practiced, with modification, in other and different certification 
methods and schemes within the spirit and scope of the invention. Also, note that 
the need for certification and certificate revocation extends beyond certifying 
public keys and could include certifying any information. 
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One* of the preferred implementations of the various routines disclosed 
above is as a set of instructions in a code module resident in the random access 
memory of a computer. Until required by the computer, the set of instructions 
may be stored in another computer memory, for example, in a hard disk drive, or 
5 in a removable memory such as an optical disk (for eventual use in a CD ROM) 
or floppy disk (for eventual use in a floppy disk drive). In addition, although the 
various methods described are conveniently implemented in a general purpose 
computer selectively activated or reconfigured by software, one of ordinary skill in 
the an would also recognize that such methods may be carried out in hardware, in 
10 firmware, or in more specialized apparatus constructed to perform the required 
method steps. 
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What is claimed is: 



1 . A method for an authority to authenticate certificate information provided 
to a intermediary in a manner that enables an end user to verify portions of the 
information, comprising the steps of: 

(a) mapping the information into a plurality of certificate values; 
5 (b) constructing an authenticated tree having an authenticated root and 

having certificate nodes corresponding to the certificate values; 

(c) the intermediary obtaining the authenticated root and at least one of 
the certificate nodes; and 

(d) the intermediary causing the end user to receive verification data 
10 including at least one of: the authenticated root, one of the 

certificate nodes, and one of the node values of the authenticated 
tree; 

(e) the end user verifying the certificate using at least a portion the 
verification data. 



15 2. A method according to claim 1, wherein the intermediary obtains the 
authenticated root and at least one of the certificate nodes from the authority. 

3. A method according to claim 1, wherein the intermediary obtains certificate 
nodes that have changed. 

4. A method according to claim 1, wherein the end user receives the 
authenticated root from the intermediary. 

5. A method according to claim 1, wherein the end user receives the 
authenticated root from the authority. 

6. A method according to claim 1, wherein the end user receives at least one 
of the certificate nodes from the intermediary. 

1. A method according to claim 1, wherein the end user receives at least one 
of the certificate nodes from the authority. 
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8. A method according to claim 1, wherein the end user obtains certificate 
nodes that have changed. 

9. A method according to claim 1, wherein the root is authenticated with a 
digital signature. 

10. A method according to claim 9, wherein the digital signature is verifiable 
by the end user. 

11. A method according to claim 1, wherein the certificate values indicate 
which certificates have been revoked. 

12. A method according to claim 11, wherein the certificate values include a 
date of revocation for the certificates that have been revoked. 

13. A method according to claim 1, wherein the certificate values indicate 
which certificates are valid. 

14. A method according to claim 13, wherein the certificate values include a 
date of expiration for the certificates that are valid. 

15. A method according to claim 1, wherein the certificate values indicate 
which certificates have been issued. 

16. A method according to claim 15, wherein the certificate values include a 
date of issue for the certificates that have been issued. 

17. A method according to claim 1, wherein the certificate values indicate 
which certificates have been revoked and which certificates are valid. 

18. A method according to claim 1, wherein the certificate values indicate 
which certificates have been revoked and which certificates have been issued. 
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19. A method according to claim 1, wherein the certificate values indicate 
which certificates are valid and which certificates have been issued. 

20. A method according to claim 1, wherein the certificate values indicate 
which certificates have been revoked, which certificates are valid, and which 
certificates have been issued. 

21. A method according to claim 1 , wherein values of the internal nodes are 
obtained by performing a one-way hash of the values of the children thereof. 

22. A method according to claim 21, wherein the value of at least one of the 
internal nodes is obtained by performing a one-way hash of a combination of the 
values of the children of the internal node and a value of the internal node. 

23. A method according to claim 22, wherein the value of the internal node 
indicates a position of the internal node within the tree. 

24. A method according to claim 1, wherein at least one of the certificate 
nodes corresponds to more than one certificate. 

25. A method according to claim 1, wherein the steps of mapping and 
constructing are performed by the authority. 

26. A method according to claim 11, wherein the steps of mapping and 
constructing are performed by the authority. 

27. A method according to claim 1, wherein certificate information determines 
locations of the nodes within the authenticated tree. 

28. A method according to claim 1, wherein the certificate information 
determines the certificate nodes corresponding to the certificate values mapped 
from the certificate information. 

29. A method according to claim 28, wherein positions of nodes within the 
authenticated tree provide at least a portion of the certificate information. 
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30. A method according to claim 29, wherein the certificate information ' 
includes serial numbers for each of the certificates. 

31. A method according to claim 26, wherein the certificate information relates 
to certificates having serial numbers that determine the certification nodes. 

32. A method according to claim 26, wherein the authority also revokes 
certificates. 

33. A method according to claim 15, wherein the steps of mapping and 
constructing are performed by the authority. 

34. A method according to claim 33, wherein the authority also issues 
certificates. 

35. A method according to claim 1, wherein the certificate values correspond 
to serial numbers of the certificates. 

36. A method according to claim 35, wherein the certificate values correspond 
to serial numbers of the certificates combined with additional information. 

37. A method according to claim 1, wherein the authenticated root contains 
additional information. 

38. A method according to claim 37, wherein the additional information 
includes date information. 

39. A method according to claim 37, wherein the additional information 
includes an indication of at least one of: revoked, issued, and valid for describing 
the certificate information corresponding to the certificate nodes of the 
authenticated tree. 

40. A method according to claim 1 , wherein the certificate nodes are leaf nodes 
of the authenticated tree. 
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41. A method according to claim 1, wherein the intermediary causes 
authenticating values of at least one of the certificate nodes to be provided to the 
end user. 

42. A method according to claim 1, wherein the certificate information includes 
serial numbers of the certificates. 

43. A method according to claim 42, wherein location of the certificate nodes 
within the authenticated tree varies according to the certificate values. 

44. A method for a intermediary to prove to an end user that certificate 
information is authenticated by an authority, comprising the steps of: 

(a) obtaining at least a portion of an authenticated tree having certificate 
nodes corresponding to certificate values indicative of the 

5 information; and 

(b) causing the end user to receive at least one of the following values: 
certificate values, authenticating values of certificate values, and one 
or more node values authenticated by an authority. 

45. A method according to claim 44, wherein at least one of the authenticated 
node values is the root value. 

46. A method according to claim 44, wherein the user receives at least one of: 
a certificate value, a node value, and an authenticated node value. 

47. A method according to claim 44, wherein the user uses at least a value that 
the intermediary caused the user to receive to verify the authenticity of the 
certificate information 

48. A method according to claim 47, wherein the end user verifies the 
authenticity of the certificate information via an authentication path of at least one 
certificate node 
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49. A method according to claim 44, wherein the authenticated tree values and 
the authenticated node values change over time. 

50. A method according to claim 49, wherein the intermediary causes the end 
user to receive values that have changed. 

51. A method according to claim 49, wherein the intermediary omits causing 
the user to receive at least one value, already known to the user, belonging to an 
authentication path of a certificate node corresponding to certificate information 
that the user wants to verify. 

52. A method according to claim 51, wherein the intermediary omits causing 
the user to receive a value corresponding to a node other than the root. 

53. A method according to claim 49, wherein the user asks for the value of at 
least one certificate node and wherein the intermediary omits causing the user to 
receive at least one value in an authentication path of a certificate node already 
known to the user. 

54. A method according to claim 44, wherein the intermediary sends at least 
one of: a certificate value, a node value, and an authenticated node value. , 

55. A method according to claim 54, wherein the intermediary omits sending at 
least one value already known to the user. 

56. A method according to claim 55, wherein the user sends a signal indicating 
values that the user already knows. 

57. A method according to claim 50, wherein the intermediary sends at least 
one of: a certificate value, a node value, and an authenticated node value. 

58. A method according to claim 57, wherein the intermediary omits sending at 
least one value already known to the user. 
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59. A method according to claim 58, wherein the user sends a signal indicating 
values that the user already knows. 

60. A method according to claim 44, wherein the intermediary can prove to the 
user that a certificate was never issued. 

61. A method according to claim 44, wherein the intermediary can prove to the 
user that a alleged certificate was never issued. 

62. A method according to claim 44 , wherein the intermediary can prove to the 
end user that a given serial number does not correspond to any issued certificate of 
a given CA. 

63. A method according to claim 44, wherein the certificates are public key 
certificates. 

64. A method for a intermediary to prove to an end user that certificate 
information is authenticated by an authority, comprising the steps of: 

(a) obtaining an authenticated tree having certificate nodes 
corresponding to certificate values indicative of the information; 

(b) obtaining an authenticated root of the authenticated tree, wherein the 
authenticated root proves that the authority authenticated the tree; 

(c) causing the end user to receive certificate values and to receive 
authenticating values of certificate values; and 

(d) causing the end user to receive the authenticated root, whereby the 
authenticated root and authenticating values are used by the user to 
verify the certificate values. 

65. A certificate revocation system in which one or more authorities issue and 
revoke certificates and an intermediary provides end users certificate information 
authenticated by the one or more authorities having the intermediary prove to an 
end user that a given certificate has not been issued by a given authority by a 
given date by providing a piece of information generated by the given authority. 
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66. A certificate revocation system, according to claim 65, wherein the piece of 
information includes a digital signature of the authority. 

67. A certificate revocation system, according to claim 66, wherein the piece of 
information can be verified by the end user in conjunction with a separate piece of 
information generated by the authority. 

68. A certificate revocation system, according to claim 67, wherein the 
separate piece of information includes a digital signature of the authority 

69. A certificate revocation system, according to claim 68, wherein the piece of 
information includes at least one value of a node in an authenticated tree. 

70. A certificate revocation system, according to claim 69, wherein the separate 
piece of information is the authenticated root of the authenticated tree. 
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[received by the International Bureau on 14 April 1997 (14.04.97) ; 
new claims 71-151 added; remaining claims unchanged (7 pages)] 



71. A method for authenticating information about revoked certificates, comprising the 
steps of: 

(a) storing the information about revoked certificates in an authentication tree; 
and 

(b) digitally signing the root value of the tree, wherein the root value contains 
less bits than a list of all revoked certificates. 

72. A method according to claim 71, wherein the information about revoked certificates 
stored in the authentication tree includes the serial numbers of the revoked 
certificates. 

73. A method according to claim 72, wherein the information about revoked certificates 
further includes revocation dates. 

74. A method according to claim 71, wherein digitally signing is performed by a 
certification authority. 

75. A method according to claim 73, wherein the information about revoked certificates 
is determined by a certification authority. 

76. A method according to claim 73, wherein storing information is performed by a 
certification authority. 

77. A method according to claim 71, wherein an entity that stores information also 
digitally signs the root. 

78. A method according to claim 77, wherein the entity is a certification authority. 

79. A method according to claim 77, wherein the entity is a directory. 

80. A method according to claim 71 , wherein a directory uses the authentication tree to 
prove that a certificate has been revoked. 

81. A method according to claim 80 t wherein the root is digitally signed by an entity 
other than the directory. 

82. A method according to claim 81, wherein the root is digitally signed by a 
certification authority. 

83. A method for authenticating information about valid certificates, comprising the 
steps of: 

(a) storing the information about valid certificates in an authentication tree; and 

(b) digitally signing the root value of the tree, wherein the root value contains 
less bits than a list of all valid certificates. 
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84. A method according to claim 83, wherein the information about valid certificates 
stored in the authentication tree includes the serial numbers of the valid certificates. 

85. A method according to claim 83, wherein digitally signing is performed by a 
certification authority. 

86. A method according to claim 83, wherein the information about valid certificates is 
determined by a certification authority. 

87. A method according to claim 86, wherein storing information is performed by a 
certification authority. 

88. A method according to claim 83, wherein an entity that stores information also 
digitally signs the root. 

89. A method according to claim 88, wherein the entity is a certification authority. 

90. A method according to claim 88, wherein the entity is a directory. 

91. A method according to claim 83, wherein a directory uses the authentication tree to 
prove that a certificate is valid. 

92. A method according to claim 91, wherein the root is digitally signed by an entity 
other than the directory. 

93. A method according to claim 92, wherein the root is digitally signed by a 
certification authority. 

94. A method for authenticating information about valid and revoked certificates, 
comprising the steps of: 

(a) storing in an authentication tree information indicating whether each 
certificate is valid or revoked; and 

(b) digitally signing the root value of the tree, wherein the root value contains 
less bits than a list of all certificates. 

95. A method according to claim 94, wherein the information includes the serial 
numbers of the certificates. 

96. A method according to claim 95, wherein information about revoked certificates 
further includes revocation dates. 

97. A method according to claim 94, wherein digitally signing is performed by a 
certification authority. 
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98. A method according to claim 97, wherein the information is determined by a 
certification authority. 

99. A method according to claim 98, wherein storing information is performed by a 
certification authority. 

100. A method according to claim 94, wherein an entity that stores information also 
digitally signs the root. 

101. A method according to claim 100, wherein the entity is a certification authority. 

102. A method according to claim 100, wherein the entity is a directory. 

103. A method according to claim 94, wherein a directory uses the authentication tree to 
prove that a certificate has been revoked. 

104. A method according to claim 94, wherein a directory uses the authentication tree to 
prove that a certificate is valid. 

105. A method according to claim 103, wherein the root is digitally signed by an entity 
other than the directory. 

106. A method according to claim 105, wherein the root is digitally signed by a 
certification authority. 

107. A method according to claim 104, wherein the root is digitally signed by an entity 
other than the directory. 

108. A method according to claim 107, wherein the root is digitally signed by a 
certification authority. 

109. A method for providing authenticated information about a revoked certificate, 
comprising the steps of: 

(a) providing an information value stored in an authentication tree, wherein the 
information value contains information about the revoked certificate; 

(b) providing an authenticated root value of the authentication tree; and 

(c) providing an authentication path for the information value. 

110. A method according to claim 109, wherein the information value includes the serial 
numbers of the revoked certificate, 

111. A method according to claim 1 10, wherein the information value includes a 
revocation date. 



27 

AMENDED SHEET (ARTICLE 19) 



WO 97/16905 



PCTAJS96/17374 



112. A method according to claim 109, wherein the root value is authenticated by a 
digital signature. 

1 13. A method according to claim 112, wherein the digital signature is provided by a 
certification authority. 

1 14. A method according to claim 112, wherein the digital signature is provided by a 
directory. 

115. A method according to claim 109, wherein the information value is stored by a 
certification authority. 

1 16. A method according to claim 109, wherein an entity that stores the information 
value also digitally signs the root of the authentication tree. 

117. A method according to claim 116, wherein the entity is a certification authority. 

118. A method according to claim 1 16, wherein the entity is a directory. 

1 19. A method according to claim 109, wherein the authentication path is provided by a 
directory. 

120. A method according to claim 119, wherein the directory stores the information 
value and authenticates the root value. 

121. A method according to claim 71, wherein the information about a particular revoked 
certificate is stored in a node of the authentication tree that depends upon the 
particular revoked certificate. 

122. A method according to claim 82, wherein the information about a particular revoked 
certificate is stored in a node of the authentication tree that depends upon the 
particular revoked certificate. 

123. A method according to claim 94, wherein the information about a particular revoked 
certificate is stored in a node of the authentication tree that depends upon the 
particular revoked certificate 

124. A method according to claim 109, wherein the information about the revoked 
certificate is stored in a node of the authentication tree that depends upon the 
revoked certificate. 
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125. A method of providing information about revoked certificates, comprising the steps 
of: 

(a) storing, in nodes of a tree, information about the revoked certificates; 

(b) for each internal node of the tree, obtaining a value that binds each internal 
node to values of the children thereof; and 

(c) authenticating a root value of the tree. 

126. A method according to claim 125, wherein obtaining a value for a particular 
internal node includes evaluating a one-way function on at least values indicative of 
the children of the particular internal node. 

127. A method according to claim 125, wherein the node in which information about a 
particular revoked certificate is stored depends on the particular revoked certificate. 

128. A method according to claim 126, wherein a particular revoked certificate 
determines the path from the root of the tree to the node storing information about 
the particular revoked certificate. 

129. A method according to claim 126, wherein the node in which information about a 
particular revoked certificate is stored depends on the particular revoked certificate. 

130. A method according to claim 125, wherein a particular revoked certificate 
determines the path from the root of the tree to the node storing information about 
the particular revoked certificate. 

131. A method according to claim 125, wherein the root value is digitally signed by a 
CA. 

132. A method according to claim 125, wherein the root value is digitally signed by a 
directory. 

133. A method according to claim 127, wherein the root value is digitally signed by a 
CA. 

134. A method according to claim 128, wherein the root value is digitally signed by a 
CA. 

135. A method according to claim 127, wherein the root value is digitally signed by a 
directory. 

136. A method according to claim 128, wherein the root value is digitally signed by a 
directory. 
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137. A method according to claim 125, wherein information on at least two certificates is 
stored in the same node of the tree. 

138. A method according to claim 127, wherein information on at least two certificates is 
stored in the same node of the tree. 

139. A method according to claim 128, wherein information on at least two certificates is 
stored in the same node of the tree. 

140. A method of providing information about valid and revoked certificates, comprising 
the steps of: 

(a) storing, in nodes of a tree, information about certificates with an indication 
of whether the certificates are revoked; 

(b) for each internal node of the tree, obtaining a value that binds each internal 
node to values of the children thereof; and 

(c) authenticating a root value of the tree. 

141 . A method according to claim 140, wherein obtaining a value for a particular 
internal node includes evaluating a one-way function on at least values indicative of 
the children of the particular internal node. 

142. A method according to claim 140, wherein the node in which information about a 
particular revoked certificate is stored depends on the particular revoked certificate. 

143. A method according to claim 141, wherein a particular revoked certificate 
determines the path from the root of the tree to the node storing information about 
the particular revoked certificate. 

144. A method according to claim 141, wherein the node in which information about a 
particular revoked certificate is stored depends on the particular revoked certificate. 

145. A method according to claim 140, wherein a particular revoked certificate 
determines the path from the root of the tree to the node storing information about 
the particular revoked certificate. 

146. A method of providing information about valid certificates, comprising the steps of: 

(a) storing, in nodes of a tree, information about the valid certificates; 

(b) for each internal node of the tree, obtaining a value that binds each internal 
node to values of the children thereof; and 

(c) authenticating a root value of the tree. 
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147. A method according to claim 146, wherein obtaining a value for a particular 
interna] node includes evaluating a one-way function on at least values indicative of 
the children of the particular internal node. 

148. A method according to claim 146, wherein the node in which information about a 
particular revoked certificate is stored depends on the particular revoked certificate. 

149. A method according to claim 146, wherein a particular revoked certificate 
determines the path from the root of the tree to the node storing information about 
the particular revoked certificate. 

150. A method according to claim 147, wherein the node in which information about a 
particular revoked certificate is stored depends on the particular revoked certificate. 

151. A method according to claim 148, wherein a particular revoked certificate 
determines the path from the root of the tree to the node storing information about 
the particular revoked certificate. 
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